Java Database Programming with JDBC Java Database Programming with JDBC
by Pratik Patel
Coriolis, The Coriolis Group
ISBN: 1576100561   Pub Date: 10/01/96
  

Previous Table of Contents Next


Chapter 9
Java And Database Security

Security is at the top of the list of concerns for people sharing databases on the Internet and large intranets. In this chapter, we’ll have a look at security in Java and how Java/JDBC security relates to database security. We’ll also have a peek at the new security features planned for Java, which will incorporate encryption and authentication into the JDBC.

Database Server Security

The first issue I’d like to tackle, and the first one you need to consider, is the security of your actual database server. If you are allowing direct connections to your database server from your Java/JDBC programs, you need to prepare for a number of potential security pitfalls. Although security breaks are few and far between, I advise you to cover all the angles so you don’t get caught off-guard.

Rooting Out The Packet Sniffers

Information is sent over networks in packets, and packet sniffing happens because a computer’s network adapter is configured to read all of the packets that are sent over the network, instead of just packets meant for that computer. Therefore, anyone with access to a computer attached to your LAN can check out all transactions as they occur. Of course, a well-managed network and users you can trust are the best methods of preventing an inside job. Unfortunately, you must also consider another possibility: the outside threat. The possibility that someone from outside your LAN might break into a computer inside your LAN is another issue altogether; you must make sure that the other computers on your LAN are properly secured. To prevent such a situation, a firewall is often the best remedy. Though not completely foolproof, it does not allow indiscriminate access to any computers that are behind the firewall from outside. There are several good books on basic Internet security, and this book’s Website contains a list of URLs that highlight several books on firewalls.

Packet sniffing doesn’t necessarily involve only your local network; it can occur on the route the packet takes from the remote client machine somewhere on the Internet to your server machine. Along one of the many “hops” a packet takes as it travels across the Internet, a hacker who has gained entry into one of these hop points could be monitoring the packets sent to and from your server. Although this is a remote possibility, it’s still a possibility. One solution is to limit the IP addresses from which connections to the database server can be made. However, IP authorization isn’t bulletproof either—IP spoofing is a workaround for this method. For more information on these basic security issues, please see this book’s Web site for references to security material.

Web Server CGI Holes

If you only allow local direct access to your database server via pre-written software, like CGI scripts run from Web pages, you’ll still find yourself with a possible security hole. Some folks with too much time on their hands take great pleasure in hacking through CGI scripts to seek out unauthorized information. Are you vulnerable to this type of attack? Consider this situation: You have a CGI script that searches a table. The HTML form that gives the CGI its search information uses a field containing a table name; if a hacker realizes that you are directly patching in the table name from the HTML page, it would be easy to modify the CGI parameters to point to a different table. Of course, the easy solution to this scenario is to check in the CGI script that only the table you intend to allow to be queried can be accessed.

For in-house distribution of Java programs that access database servers, many of these security considerations are minimal. But for Internet applications, such as a merchandising applet where a user enters a credit card number to purchase some goods, you not only want to send this data encrypted to the Web server, but you want to protect the actual database server that this sensitive data is stored on.

Finding A Solution

So how do we deal with these security holes? The most straightforward way is to use a database server that implements secure login encryption. Some database servers do this already, and with the proliferation of “Web databases,” login encryption is likely to be incorporated into more popular database servers in the future. The other solution, which is more viable, is to use an application server in a three-tier system. First, the Java program uses encryption to send login information to the application server. Then, the application server decodes the information. And finally, the application server sends the decoded information to the database server, which is either running on the same machine or on a machine attached to a secure local network. We’ll discuss application servers in more detail in Chapter 11.

Another solution involves using the Java Security API, currently under development at Javasoft. This API, which provides classes that perform encryption and authentication, will be a standard part of the Java API and will allow you to use plug-in classes to perform encryption on a remote connection.

As a user, how do you know if the Java applet you’re getting is part of a front for an illegitimate business? The Java Commerce API addresses the security issue of determining whether an applet is from a legitimate source by using digital signatures, authorization, and certification. Both the Java Commerce API and Java Security API will likely be incorporated into Web browsers’ Java interpreters, and will also be linked in heavily with the security features of the Web browser itself. At the time this manuscript was written, however, these APIs were still under construction.

Applet Security: Can I Trust You?

As we’ve seen, setting up safe connections is quite possible. However, applet security is an entirely different issue. This aspect of security, where an applet that has been downloaded to your computer is running in your Web browser, has been under scrutiny since Java-enabled Web browsers appeared.


Previous Table of Contents Next